Hi @JoeCqupt ! Thank you for looking into this; it's indeed a frequent request to be able to exclude one or more recipes, which we have so far pushed back upon. The reason is it's typically possible to work around such issues by creating a separate rewrite.yml description file, which only contains the desired recipes.

It's more complicated than the current implementation to reliably implements exclusions, as recipes can also directly invoke each other, which is becoming quite common as well. I believe such direct invocations would not be picked up with the current implementation, and would not be trivial to implement.

There's also potential for issues when recipes assume preceding recipes have run before they make their own changes, which will be hard to reliably detect and prevent. In the past for instance we've had to request not to migrate just yet to JUnit Jupiter as part of the Spring Boot 2.4 migration. If we would allow exclusions, then we suddenly can't be certain anymore that users are on JUnit Jupiter in any of the Spring Boot 2.4+ recipes, which really complicates the logic for all recipes involved. There's more such examples where exclusions might trip up migrations in unexpected ways, which is why we've found it easier not to support exclusions rather than open it up for potential misuse, which we then have to counteract.

We do try to be conservative with the recipes we include with our common larger composite recipes, such that there should rarely be a need for exclusions, especially with the rewrite.yml workaround available as well. When issues do occur with included recipes, we prefer to fix those bugs quickly rather than allow for exclusions that might lead to harder to debug issues down the line.

So as much as we appreciate you contributing to the project, at this stage I'm uncertain whether this particular proposal is one we would be open to adopt. I'll raise it again internally, but wanted to give you this background such that you know it's both more complicated than expected, and has a potential for further issues that we hope to prevent.

Feel free to add your own perspective here as well; you likely have a couple of use cases that you might have hoped to use this feature for, and I hope we are able to work through those for you in some other way!

ok. i get it.

Yes sorry to see you've spent time on something we won't continue with for now. You're always welcome to contribute in some other way! You can also join our slack if there's anything you'd want to discuss up front before diving in. And like I said before: happy to work through any issues that prompted you to consider exclusions!

Maybe there is a possibility to provide an optional .enabled configuration flag for recipes that are rather optional ?

For example: UpgradeSpringBoot_3_1 transitively pulls in org.openrewrite.java.spring.ImplicitWebAnnotationNames, removing explicitly named request-parameters from RestController signatures. If this goes against my projects' style guide, I might be better off not using OpenRewrite ?

Hi @tgeens ; Sorry to hear you're unhappy with the inclusion of ImplicitWebAnnotationNames. For reference that comes in through our Spring Boot 2 best practices, which we run as part of our Migration to Spring Boot 2.0. That's indeed potentially a lot of yaml recipes to copy if you were to follow the above recommended approach.

It's not immediately clear to me which recipes you'd like to add a .enabled configuration option to; it sounds very much like a skip option by another name to me, which would suffer from the same drawbacks as outlined above.

Perhaps you'd be interested in following this PR, which aims to allow you to run individual minor Spring release migrations in isolation. That could provide you with an alternative here, as you likely already made the leap from 1.5 to 2.x+. Could that be a way forward for you?

These days you can create your own custom recipe based off of an existing recipe most easily through the Moderne recipe builder. You can read more about the new recipe builder on the Moderne blog. We think this is the best way forward to allow for customization. Hope that helps!